rimage: manifest: Make "cold" section size 0 when not used by dbaluta · Pull Request #10612 · thesofproject/sof

dbaluta · 2026-03-09T16:04:06Z

There are some non-critical data and code sections that are kept in DRAM to be accessed and executed from there without being copyind to SRAM.

Such sections are marked as detached and linked into a separate "cold.mod" module.

rimage considers zones starting at SOF_MODULE_DRAM_LINK_START to SOF_MODULE_DRAM_LINK_END to be cold and links them separately.

On i.MX8MP for M7 support this overalps with ITCM/DTCM/OCRAM areas which causes boot problems.

So, treat all sections as SRAM when CONFIG_COLD_STORE_EXECUTE_DRAM is not enabled by making DRAM link sections size equal to 0 in this case.

Closes: #10602

There are some non-critical data and code sections that are kept in DRAM to be accessed and executed from there without being copied to SRAM. Such sections are marked as `detached` and linked into a separate "cold.mod" module. rimage considers zones starting at SOF_MODULE_DRAM_LINK_START to SOF_MODULE_DRAM_LINK_END to be cold and links them separately. On i.MX8MP for M7 support this overalps with ITCM/DTCM/OCRAM areas which causes boot problems. So, treat all sections as SRAM when CONFIG_COLD_STORE_EXECUTE_DRAM is not enabled by making DRAM link sections size equal to 0 in this case. Closes: thesofproject#10602 Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>

Copilot

Pull request overview

This PR fixes a boot problem on i.MX8MP (M7) where ITCM/DTCM/OCRAM memory sections were incorrectly treated as "detached" (cold/DRAM) by rimage, causing them to be omitted from the output image. The fix makes SOF_MODULE_DRAM_LINK_END equal to SOF_MODULE_DRAM_LINK_START (both 0) when CONFIG_COLD_STORE_EXECUTE_DRAM is not enabled, effectively collapsing the DRAM link range to empty and ensuring all sections are treated as SRAM.

Changes:

When CONFIG_COLD_STORE_EXECUTE_DRAM is disabled, SOF_MODULE_DRAM_LINK_END is defined as SOF_MODULE_DRAM_LINK_START (0), making the DRAM detection range empty.
When CONFIG_COLD_STORE_EXECUTE_DRAM is enabled, behavior is unchanged (SOF_MODULE_DRAM_LINK_END = 0x08000000).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-03-09T16:09:59Z

tools/rimage/src/include/rimage/sof/user/manifest.h

+#if CONFIG_COLD_STORE_EXECUTE_DRAM
 #define SOF_MODULE_DRAM_LINK_END	0x08000000
+#else
+#define SOF_MODULE_DRAM_LINK_END	SOF_MODULE_DRAM_LINK_START
+#endif


The comment block above SOF_MODULE_DRAM_LINK_START (lines 253–258) only accurately describes the behavior when CONFIG_COLD_STORE_EXECUTE_DRAM is enabled. After this change, when the config is not enabled, SOF_MODULE_DRAM_LINK_END equals SOF_MODULE_DRAM_LINK_START (i.e., 0), making the DRAM link range empty and disabling detached-section treatment entirely. The comment should be updated to reflect this conditional behavior — for example, noting that when CONFIG_COLD_STORE_EXECUTE_DRAM is not set, the range is empty and no sections are treated as detached.

lyakh · 2026-03-10T09:12:02Z

@dbaluta The change looks good, but CI fails, and I think I know why. That header that you're modifying is also included for rimage build and there CONFIG_COLD_STORE_EXECUTE_DRAM isn't set. So you need to modify your condition to something like #if CONFIG_COLD_STORE_EXECUTE_DRAM || !CONFIG_ZEPHYR_SOF_MODULE - you should be able to build test it (including rimage of course) for PTL too
UPDATE: but then it will break rimage for you again... Maybe rimage build should also include autoconf.h but that might be a bit more difficult...
UPDATE 2: this would be a bit controversial because we would prefer to have a single rimage executable for all architectures, but in a way this is already not the case: those DRAM start and end addresses are clearly architecture specific

dbaluta · 2026-03-10T21:25:22Z

@lyakh oh this is so unfortunate. Yes, I would also prefer same rimage for all architectures. Maybe add a runtime parameter to ignore detached sections.

lyakh · 2026-03-11T07:25:22Z

@lyakh oh this is so unfortunate. Yes, I would also prefer same rimage for all architectures. Maybe add a runtime parameter to ignore detached sections.

@dbaluta yep, I think that would be better, then we'd also need to change xtensa-build-zephyr.py to supply correct parameters. If you want to do that - I think that would be welcome, but since effectively rimage already is platform-dependent, I think as a bug-fix we can accept including autoconf.h

dbaluta · 2026-03-11T14:17:18Z

@dbaluta yep, I think that would be better, then we'd also need to change xtensa-build-zephyr.py to supply correct parameters. If you want to do that - I think that would be welcome, but since effectively rimage already is platform-dependent, I think as a bug-fix we can accept including autoconf.h

I'm trying to figure out how to generate autoconf.h before building the rimage so I can include it. Looks like now the rimage is build first and then fw compilation starts later.

dbaluta · 2026-03-12T15:49:04Z

@lyakh Using CONFIG_* from a generated header file based on platform config to compile rimage is complicated and error prone. I think the best course of action here is to make use of toml config files.

Will send a patch with this idea.

lgirdwood · 2026-03-12T15:58:41Z

I'm trying to figure out how to generate autoconf.h before building the rimage so I can include it. Looks like now the rimage is build first and then fw compilation starts later.

Btw, no objections if you want to ask copilot to change rimage from autotools to CMake if this makes things easier going forward.

dbaluta · 2026-03-12T16:12:08Z

I'm trying to figure out how to generate autoconf.h before building the rimage so I can include it. Looks like now the rimage is build first and then fw compilation starts later.

Btw, no objections if you want to ask copilot to change rimage from autotools to CMake if this makes things easier going forward.

I think rimage is already using cmake, right?

The point here is that we need the generated header file with config symbols (build-imx8m/zephyr/include/generated/zephyr/autoconf.h) before compiling rimage so that we can figure out platform config.

So we need to do something like this:

generate autoconf.h for given platform
build rimage
build the given platform

This ping pong makes me think this solution is complicated.

My approach right now is to use tools/rimage/config/ toml file maybe something like this:

version = [1, 5]

[adsp]
name = "skl"
image_size = "0x200000" # (30 + 2) bank * 64KB
alias_mask = "0xE0000000"
+module_dram_link_start = <>
+module_dram_link_end=<>

OR myabe just use the machine name at runtime and figure out when to add the dram_link area.

Anyhow, I'll investigate more not sure which solution would be faster to implement.

lyakh · 2026-03-13T07:39:50Z

@lyakh Using CONFIG_* from a generated header file based on platform config to compile rimage is complicated and error prone. I think the best course of action here is to make use of toml config files.

Will send a patch with this idea.

@dbaluta interesting, when building SOF for Intel ADSP the xtensa-build-zephyr.py script among other things does:

build rimage
run west build which builds zephyr.elf and calls rimage to sign it and generate the respective .ri

So, if we wanted to build rimage after creating autoconf.h we'd have to execute step (2) without the signing step, then build rimage (1) and then run it to sign the image. So, yes, this looks like a rather intrusive change, agree.

Otherwise, if you're considering adding this to toml, is it still easier than making it a run-time parameter for rimage?

dbaluta · 2026-03-13T14:38:09Z

Otherwise, if you're considering adding this to toml, is it still easier than making it a run-time parameter for rimage?

Runtime param looks the easiest approach: Please have a look #10624

Copilot AI review requested due to automatic review settings March 9, 2026 16:04

dbaluta requested review from kv2019i, lbetlej, lgirdwood, mmaka1 and plbossart as code owners March 9, 2026 16:04

dbaluta force-pushed the fix_cold_store branch from 66b6120 to 9d8cf68 Compare March 9, 2026 16:04

Copilot started reviewing on behalf of dbaluta March 9, 2026 16:06 View session

Copilot AI reviewed Mar 9, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rimage: manifest: Make "cold" section size 0 when not used#10612

rimage: manifest: Make "cold" section size 0 when not used#10612
dbaluta wants to merge 1 commit intothesofproject:mainfrom
dbaluta:fix_cold_store

dbaluta commented Mar 9, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Mar 9, 2026

Uh oh!

lyakh commented Mar 10, 2026 •

edited

Loading

Uh oh!

dbaluta commented Mar 10, 2026

Uh oh!

lyakh commented Mar 11, 2026

Uh oh!

dbaluta commented Mar 11, 2026 •

edited

Loading

Uh oh!

dbaluta commented Mar 12, 2026 •

edited

Loading

Uh oh!

lgirdwood commented Mar 12, 2026

Uh oh!

dbaluta commented Mar 12, 2026

Uh oh!

lyakh commented Mar 13, 2026

Uh oh!

dbaluta commented Mar 13, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

dbaluta commented Mar 9, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

lyakh commented Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dbaluta commented Mar 10, 2026

Uh oh!

lyakh commented Mar 11, 2026

Uh oh!

dbaluta commented Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dbaluta commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lgirdwood commented Mar 12, 2026

Uh oh!

dbaluta commented Mar 12, 2026

Uh oh!

lyakh commented Mar 13, 2026

Uh oh!

dbaluta commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

lyakh commented Mar 10, 2026 •

edited

Loading

dbaluta commented Mar 11, 2026 •

edited

Loading

dbaluta commented Mar 12, 2026 •

edited

Loading

dbaluta commented Mar 13, 2026 •

edited

Loading